Process control systems, such as distributed or scalable process control systems like those used in chemical, petroleum or other processes, typically include one or more process controllers communicatively coupled to each other, to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other of information pertaining to the field devices, and uses this information to implement a control routine and then generates control signals which are sent over the buses to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
Some process control systems, such as the DeltaV® system sold by Fisher Rosemount Systems, Inc., headquartered in Austin, Tex., use function blocks or groups of function blocks referred to as modules located in the controller and/or in field devices to perform control operations. In these cases, the controller or other device is capable of including and executing one or more function blocks or modules, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process operation, such as measuring or detecting a process parameter, controlling a device, or performing a control operation, such as the implementation of a proportional-derivative-integral (PID) control routine. The different function blocks and modules within a process control system are generally configured to communicate with each other (e.g., over a bus) to form one or more process control loops.
In some cases, function blocks may be consistent with, or similar to, the standard promulgated by Foundation™ Fieldbus. However, the term “function block” as used herein is not limited to what the DeltaV or the Fieldbus protocols identify as a function block but, instead, includes any other type of block, program, hardware, firmware, etc., associated with any type of control system and/or communication protocol and that can be used to implement some control function. Moreover, the term “function block” as used herein may generally refer to a function block that encapsulates one or several control functions, a resource block that includes one or more process parameters, a transducer block that corresponds to an interface to a sensor (e.g., temperature sensor, pressure sensor, etc.), a flowmeter, a valve actuator, etc., or any other type of block. Further, function blocks may refer to basic function blocks such as Discrete Input (DI), Discrete Output (DO), Analog Input (AO), Analog Output (AO), PID control, PD control, PI control, P control, Control Selector, Bias/Gain Station, etc., as well as to advanced function blocks such as Setpoint Ramp Generator, Timer, Analog Alarm, Discrete Alarm, Deadtime, etc. Still further, function block as used herein may be a nested block that includes several Fieldbus function blocks, for example, or even one or several nested blocks. It will be also noted that while function blocks typically take the form of objects within an object-oriented programming environment, function blocks generally can be defined using any desired data structure in any suitable software environment.
Thus, process controllers are typically programmed to execute a different algorithm, sub-routine or control loop (which are all control routines) for each of a number of different loops defined for, or contained within a process, such as flow control loops, temperature control loops, pressure control loops, etc. As indicated above, each such control loop includes one or more input blocks, such as an analog input (AI) function block, a single-output control block, such as a proportional-integral-derivative (PID) or a fuzzy logic control function block, and an output block, such as an analog output (AO) function block.
Control routines, and the function blocks that implement such routines, are configured in accordance with a number of control techniques, including PID control, fuzzy logic control, and model-based techniques such as a Smith Predictor or Model Predictive control (MPC). In model-based control techniques, the parameters used in the routines to determine the closed loop control response are based on the dynamic process response to changes in the manipulated or measured disturbances serving as inputs to the process. A representation of this response of the process to changes in process inputs may be characterized as a process model. For instance, a first-order parameterized process model may specify values for the gain, dead time, and time constant of the process.
In a typical plant, an engineer may define and configure the process control strategy using a configuration system that runs on an operator workstation. Some configuration systems may include a library to store control elements such as function blocks or modules (typically made up of a number of function blocks), so that the engineer can select and generate an instance of a selected control element according to a particular application. The configuration system may also allow the engineer to modify to alter the generated instance of the selected control element before applying the instance to the process control environment by, for example, downloading the control element to a controller or a programmable field device.
For example, a template library in a DeltaV system stores various module templates that address basic measurement and control functionality. Templates in DeltaV can be autonomous or class-based (i.e., linked to instances instantiated from the class template and capable of propagating changes in the class template to the instances). An engineer will often use one or several module templates as a starting point in defining and configuring the corresponding process control scheme. However, because typical modifications to the module templates involve a significant engineering effort and require certain check-in, check-out, and documentation procedures, working with the template library may be time-consuming.
To simplify the task of configuring a process control system, Emerson™ Process Management developed a collection of comprehensive reusable module templates and module classes known as the Project Builder Library (PBL). Generally, module templates in the PBL address the broadest contemplated range of configuration options and scenarios applicable to a particular module. The engineers who contribute to PBL build upon international standards such as ISA S88.0, IEC 61508, IEC 61131-3, etc. and incorporate experience and best practices from many hours of application and project engineering. Using PBL, an engineer can select a module template, modify values of module parameters to enable and configure the desired features, and disable the features unnecessary for the particular application. For example, a certain template may allow eight possible inputs into a certain function block, and may accordingly include eight input blocks corresponding to these eight inputs. A user who needs only one of these inputs could effectively disable seven of the eight inputs by assigning the value FALSE to the corresponding parameters. A typical PBL template thus includes more features than a DeltaV library module defined for a similar purpose. For example, a PBL template for Continuous Control may include all the features of the corresponding DeltaV template, as well as additional features related to equipment arbitration, support for four track inputs with enable/disable capability and first out detection, conditional alarming with enable/disable capability and operator access, controls to set the status of RCAS_IN and ROUT_IN channels, mode locking to optionally prevent operators from accessing the module, a failure parameter, etc. In short, a PBL module template is likely to include all the functionality of a module an engineer may need for a particular project, and to use the module the engineer normally must change only some or all values of module parameters.
While PBL can significantly simplify the process of configuring process control, PBL module templates unfortunately require a relatively large amount of controller memory. In particular, because engineers customize module templates by modifying module parameters, each instance inherits all function blocks from the parent module template, along with the associated parameters, regardless of whether a particular function block is operative in the instance. Moreover, PBL templates do not always provide the “what you see is what you can have” user experience because each module instance retains the entire functionality of the corresponding PBL module template, and engineers must examine many parameters to determine which function blocks and parameters are actually in use.